Empreinte disque des bases de données¶
2025
Les bases de données sont largement utilisées à travers le monde. Les plus populaires sont les bases de données relationnelles comme Oracle, Mysql et PostgreSQL. Mais aussi les bases de données non relationnelles telles que Mongodb, Cassandra et Redis. Il en existe bien d’autres, utilisées dans des contextes et des types variés.
L’objectif de cet article est d’analyser l’empreinte disque des bases de données comme Mysql et PostgreSQL, en fournissant également une brève comparaison avec SQLite et MongoDB.
Configuration expérimentale¶
Dans ces expériences, nous avons utilisé MySql version 15.1 et PostgreSQL version 15.13 avec les paramètres par défaut.
Nous avons créé une base de données vide avec une table nommée footprint sans index.
La table comporte trois colonnes : id, type et footprint.
La taille en octets des deux premiers champs est respectivement de 4 et 5.
Le champ fingerprint stocke des données binaires et sa taille varie selon la ligne insérée.
La définition SQL de la table est la suivante :
CREATE TABLE footprint (
id INT AUTO_INCREMENT PRIMARY KEY,
type CHAR(5),
footprint BLOB
);
CREATE TABLE footprint (
id SERIAL PRIMARY KEY,
type CHAR(5),
footprint BYTEA
);
Dans les expériences, nous insérons des lignes par lots avec des données aléatoires basées sur des paramètres tels que la taille du blob. Pour une quantité totale de données à insérer, nous mesurons l’empreinte disque des données de la table dans le dossier de contenu.
Paramètres étudiés¶
Nous étudions l’impact de plusieurs paramètres (tab. paramètres étudiés),
et en particulier l’impact sur l’empreinte disque du paramètre blob size.
Nom |
Valeur par défaut |
Description |
|---|---|---|
Blob size |
[500, 40000] octets |
Taille du blob |
Batch size |
1 ligne |
Nombre de lignes à insérer puis committer à la fin |
Total inserted size |
1 Go |
Quantité totale de données insérées pour une exécution |
innodb_page_size |
16KB |
MariaDB uniquement : taille de page innodb |
Selon l’expérience, la taille du blob à chaque insertion peut être identique ou suivre une loi de distribution avec une moyenne et un écart type.
Pour une comparaison complète, nous évaluons MariaDB v15.1, MongoDB v8.0.12, PostgreSQL v15.13, et SQLite3 sur divers scénarios. L’environnement d’exécution est Debian 12 (bookworm).
Résultats¶
Dynamique de croissance de la taille des tables¶
Nous analysons la dynamique de croissance de l’empreinte disque (fig. dynamique), nous insérons les données par lots de lignes, dans notre cas la taille du lot est 1 et le nombre d’octets par ligne est fixe. Nous observons que quelle que soit la taille du blob et la base de données, la croissance de l’empreinte est linéaire.
Fig. 7 Dynamique de l’empreinte disque pour différentes tailles de blob, à gauche MariaDB et à droite PgSQL.¶
Champ blob : taille uniforme¶
Nous analysons l’impact sur l’empreinte en fonction de la taille uniforme du blob, avec une quantité totale de données insérées de 1Go. Nous insérons et committons chaque ligne avec une taille de blob spécifique.
Fig. 8 Empreinte disque en fonction de la taille du blob, à gauche MariaDB et à droite PgSQL.¶
Fig. 9 Empreinte disque en fonction de la taille du blob pour SQLite3.¶
Fig. 10 Empreinte disque en fonction de la taille du blob pour MongoDB.¶
En fonction de la taille du blob, nous observons les éléments suivants :
Pour MariaDB, l’empreinte disque a un impact significatif pour des tailles de blob spécifiques :
5250.Pour PgSQL, l’impact sur l’empreinte disque est limité, en particulier lorsque la taille du blob dépasse 8000 octets.
Par ailleurs, au-delà des variations de l’empreinte disque, la consommation d’espace disque pour mariadb peut atteindre le double de l’espace par rapport à la quantité totale insérée.
MariaDB : innodb_page_size¶
Le paramètre innodb_page_size définit la taille de page pour le moteur InnoDB. Par défaut à 16KB, il est recommandé, selon la documentation, de l’aligner sur la taille de bloc de votre périphérique de stockage.
Selon le paramètre innodb_page_size, l’impact sur l’espace disque varie considérablement.
Par exemple, avec un BLOB de 5250 octets et une taille de page augmentée de 16KB à 64KB, nous pouvons réduire l’empreinte disque de 26%.
Cependant, si ce paramètre est mal configuré, cela peut entraîner une surconsommation significative d’espace disque. C’est le cas avec des BLOBs de 16 500 octets, entraînant un facteur de consommation de 4.
innodb_page_size |
5250 |
16500 |
|---|---|---|
16 |
1.58 |
2.01 |
32 |
1.28 |
2.03 |
64 |
1.18 |
4.04 |
Fig. 11 Empreinte disque en fonction de la taille du blob selon le paramètre innodb_page_size pour Mariadb,
à gauche vue d’ensemble et à droite zoom sur la plage de taille de blob : [500, 15000].¶
En conclusion, il est nécessaire d’analyser la distribution de vos échantillons de données pour déterminer efficacement la valeur optimale de ce paramètre, car il existe une sensibilité à ce paramètre qui peut affecter positivement ou négativement l’empreinte disque. Si la distribution statistique des tailles de blob ne peut pas être déterminée, il est généralement préférable de conserver la configuration par défaut ou recommandée.
Stocker les données de manière ordonnée¶
Lorsque nous utilisons des blobs de taille variable, l’ordre dans lequel ils sont insérés dans la table peut influencer la taille de son empreinte disque. Dans la figure, nous remarquons qu’un ensemble ordonné par taille de blob entraîne une empreinte disque plus faible comparé à un ordre aléatoire.
Fig. 12 Dynamique de l’empreinte disque pour un jeu de données à distribution uniforme de la taille de blob entre [4250, 6250] sous Mariadb.¶
La question que nous pouvons nous poser est de savoir s’il existe une meilleure relation d’ordre permettant de minimiser l’empreinte disque.